COMMENT ⊗   VALID 00011 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	.COMMENT OGDEN 2/23/73, REVISED 2/24,2/25,2/26 
C00003 00003	.SEC GENERAL PLAN FOR POLOS EDITING SYSTEMS
C00007 00004	.SEC USER INTERFACES
C00018 00005	.SEC STRUCTURES
C00028 00006	.SEC EDITING CONSIDERATIONS
C00033 00007	.SEC FORMATTING METHODS
C00041 00008	.SEC COMMUNICATIONAL INTENTION
C00044 00009	.SEC IMPLEMENTATIONS
C00049 00010	.SEC MEASUREMENT AND EVALUATION
C00052 00011	.STANDARD BACK
C00053 ENDMK
C⊗;
.COMMENT OGDEN 2/23/73, REVISED 2/24,2/25,2/26 ;
.NOJUST
.BEGIN CENTER
.GROUP SKIP 10 ; TURN ON "{" ;
A Vague and Noncommittal Overview of OGDEN:

an Overly General Display Editor for Non-programmers


compiled by Larry Tesler
from various meetings of the POLOS project

{DATE}
.END
.SKIP 8
.BEGIN FLUSH LEFT
Third draft.
Please make comments, corrections, and additions.


Distribution:

POLOS Project
.END
.require "pubmac.nun[2,TES]" source_file
.standard front("I", "!.A")
.COUNT PAGE
.every footing(,{PAGE},)
.EVERY HEADING(,{DATE},OGDEN OVERVIEW)
.SEC GENERAL PLAN FOR POLOS EDITING SYSTEMS
.SS LONG-TERM GOALS
We would like to develop a personal office computer
linked to others of its kind and to shared resources
such as microfiche libraries, XGPs, and outside phone
lines.  The system should be oriented towards common office
use.  Functions should
include Composition, Display, Printing, Filing, Distribution, and
Communication.
Media shall include text, graphics, and voice.

.SS SHORT-TERM GOALS
During the next year, we shall experiment with
a distributed system demonstrating some of the
facilities desired in the eventual system.  We hope to
learn about various system organizations
and begin to learn about user interfaces.

We will decide in summer 1973 whether to use NOVAs, ALTOs,
or a combination of these in the initial
experiments, and in what programming language to build
the system.

.SS OGDEN
Between now and the summer, we will try to construct an overly
general display-oriented editor herein called "OGDEN".
It will be written in LISPX to take advantage of its
data structure, debugging, and undoing capabilities.
OGDEN will be a single-user system to be used as a test bed
for new ideas.

We will concentrate at first on solving
problems we do not understand, such as multiple structures
describing the same document and distributed control.

OGDEN will be user interface-independent.  This will allow us
to construct different interfaces without redesign of the whole
system and to compare them in a common framework.

A set of implementation notes on the OGDEN system is being maintained
during its development.

.SS INTERIM FACILITIES
To handle the PARC workload while the new systems are under
development, we will import first TNLS and then DNLS to our
MAXC.  We will also participate in the development of a successor
to PUB during the summer so that we will have adequate
formatting capabilities without depending on
an ever-changing experimental system.
.SEC USER INTERFACES
.SS FEEDBACK
At least four feedback media will be available:
Text, Marks, Graphics, and Audio.
We will study whether to use each of these and if so where and
how to use them.

For text feedback, there are questions of continuous feedback
versus periodic feedback.  For example, when text is inserted,
should the surrounding text be realigned at each character
as is done at SU-AI or only at the end of the insert command
as at ARC?  Where should the text being inserted be displayed,
and should it stand out in some way?

Mark feedback may be useful for delimiting
segments that are to be operated upon.  Where
should marks be placed with respect to the segment;
what should they look like; how should they behave?

Drawn boxes may be more useful than marks
for delimiting sections of text as well as drawings and other
document units.  Graphic devices that convey the idea of change
may also be
useful: arrows for translation, rotation, and expansion;
explosions for deletion, and so on.

Audio feedback includes voice acknowledgment, voice error
messages, and characteristic tones.

.SS CONTROL
The same media are available for control as for feedback.

Text commands may be entered by keyboard or keyset.
Abbreviation mechanisms should be studied.  Ways to enter
nonstandard characters must be designed.

Bug marks may be positioned by a mouse or similar device.
There is a question of where to place the mark with respect to
mouse position.  The user may have designated a "command-scope" (such as
character, word, or statement) before placing the mark,
or the system may place the mark exactly as indicated and then
deduce the command-scope from the location of pairs of marks.

A box may be drawn as a series of lines or may be cued by
noting just a few points.  If there is a command-scope, only one
or two points are needed; if not, then more points are
needed but the command-scope is implied.

Voice commands will be limited by speech-analysis technolgy,
but we may not want to use voice control extensively
because of user inconvenience.

Commands will be interpreted with respect to the context in which
the user is working; this should reduce the complexity of the command
language.  Other DWIM-like facilities, such as spelling correction,
will further ease the user interface.

.SS POSTING BOARDS
The various modules of the system will communicate with each other
and with the user through "posting boards".  Posting boards list
the contents of the file being edited,
state information such as ranges, modes, and view specifications,
and control information such as requested actions,
confirmations, and error messages.

.SS WINDOW PANES
The user's display screen is a paned window.  Each pane provides a
view of a portion of a posting board.  The user can edit those
portions of a posting board that can be seen through the pane.

State information can be changed and commands can be given by
editing posting boards through window panes.
The command language thus becomes a shorthand notation for editing
posting boards.

System modules will also view posting boards through window panes
and use them much as the user does.

.SS UNDOING
In OGDEN, we will take advantage of the full undoing capabilities
of LISPX.  However, user systems may be restricted to simpler but
adequate capabilities. The simplest scheme is an UNDO button which
runs time backwards an event at a time.  It must be possible to make
selected changes and then run time forward again.

Nothing drastic, big, or important ever happens quickly.  After a while,
the history list can be compacted to eliminate small changes that
were made long ago.

.SS FILING
Digital and optical (microfiche) files will be provided.

File directory schemes will be toyed with.  A file directory can be
just another document.  How
does editing it affect the state of the files?

Iconic naming systems will be explored.  A picture of a room full of
cabinets with drawers and file folders is one approach to a spatial
filing system.  Or the screen can display a human figure and files
can be placed in the eyes, the pockets, etc.  File backup can use
closets, vaults, etc.  We may be able to try these out even before
graphics are available by using the character generator.

Protection should be based on the premise that a document is
private until the author releases it.  It should be easy to specify
the permissible access to a file.  Each user can have a file
management program to control and record access.

.SS DISTRIBUTION
Ways for senders to specify receivers and for receivers to specify
topics of interest will be explored.  Methods of notification and of
acknowledgment will be developed.

A reminder facility should be provided as well.

.SS COMMUNICATION
Terminals can be linked together for conferences, consultation, and
demonstrations.  Problems that arise include loci of control,
protection, and synchronization.

Voice communication is an integral part of the system.  This may be
routed through separate channels or be part of the data
communication paths.

Each participant in a conference can select what to view or ask to
view what others select, including posting boards, bug marks, and
cursors.  Selecting what to hear should work similarly.

Each terminal should be responsible for maintaining the connection
to each other terminal in a conference.  Centralization would
thwart this requirement.

.SS GRADED CAPABILITIES
A complete spectrum of capabilities should be provided from elementary
to very sophisticated.  A user should be able to accomplish
significant tasks with the simplest set of capabilities.  As
proficiency, confidence, and expectations increase, it should be
possible to acquire new skills.  With knowledge of more powerful facilities,
the user should be able to be more productive and efficient.  Furthermore,
the opportunity to learn more skills should maintain interest in the
system and encourage creative use of it.

.SS USER MODEL
The system of the user to communicate more effectively.  At the very least,
the model must include a list of system capabilities that the user has
learned.  If a secretary accidentally types a command she has never
heard of, the system will give an error message instead of doing something
incomprehensible to her.  The content of messages to the user should
take into consideration her knowledge as reflected in the model.
.SEC STRUCTURES
.SS ATOMS AND MOLECULES
A document has an unstructured existence as a collection of uniquely
named "atoms" such as characters and vectors.  An atom is
primitive and indivisible unless an atom editor is entered, just as
a file is primitive and indivisible unless a file editor is
entered.  This means that the choice of atoms is arbitrary; e.g.,
words instead of characters could be considered atomic.

The collection of atoms and molecules that comprise a document
can be structured into "molecules" in more than one way.

.SS FRAGMENT STRUCTURE
This most basic of structures is nearly linear.  The document
consists of a sequence of "fragments", each of which is guaranteed
to begin a new page (e.g., a chapter).  Each fragment consists of a
linear list of atoms, e.g., all the words in the fragment in their
galley order of appearance.

Formatting modes are generally local to fragments so that they can be
processed individually.

A sublist of a fragment list is called a "subfragment".  It can be
treated as a molecule in other structures, e.g., as a paragraph,
a text line, a phrase, or a drawing (made of vector units).
Notice that subfragments may nest as well as overlap.

.SS OUTLINE STRUCTURE
An outline structure is valuable, as demonstrated by NLS.  However,
other ways of looking at a document are equally important and we
should provide them.  

One way to display outline structure is as in NLS.  We might
explore other node-numbering systems and even graphical
display of trees.

Outline structure can also be extended upward to the organization of
file directories.

.SS INTENTIONAL STRUCTURE
This is a formal outline structure.  Headings are stated in a formal
language (with the help of DWIM) and describe the communicational
intent of the material which they head.  Examples of headings are:
"Definition of a spocket", "Construction of a spocket", "Price of a
spocket", "Addressee".

.SS GALLEY STRUCTURE
This is the primary format structure. A
fragment is divided into "boxes" such as paragraphs, diagrams, and
footnotes.  Each box is (theoretically) ticked along its left and right edges at
"group" boundaries where horizontal page cuts may be made.  A text
group consists of lines of words.  A graphics group or math group
will have an apropriate structure.

A galley structure can be displayed either to scale or "ragged", i.e., with fewer
words and larger characters on each line for easier editing.

.SS PAGINATED STRUCTURE
This is the structure of a paginated document.  It adds levels between
fragments and groups.  Thus, galley structure is fragment-box-group
while one paginated structure is fragment-page-area-column-group.
Display of paginated structure can be to scale or ragged.

.SS TOPICAL STRUCTURE
Passages relevant to a certain topic, although spread all over the document, can
be threaded together.  Topics themselves can be organized into an outline or
into an alphabetical index.   A topic outline or index covering several
documents is also useful.

.SS TABLE STRUCTURE
Two-dimensional tables should be manipulable by either rows or columns.
The row structure and column structure can be thought of as separate
to make this natural.

Tables of more dimensions occur frequently in documents when the data
depends on several variables.  These may be thought of as
multi-dimensional arrays or as tables within tables.

One-dimensional tables, either horizontal or vertical, are also common,
including most posting boards.

Although display of tables is usually governed by format structure, it
might be a useful option to have them displayed on a cartesian grid.

.SS FIELD STRUCTURE
Letters and travel forms may be rendered as field structures.  A paned
window may be regarded as a field structure whose fields are views onto
posting boards.  When a field structure is displayed, the form is
generally overlayed.

.SS CROSS-REFERENCE STRUCTURE
Cross-references should be executable like the links of NLS, but should also be
resolvable like PUB cross-references.  They form an unusual structure because
they consist of unsystematic connections between pairs of points.  To
display a connection in cross-reference structure, the screen can be split to
show the referrer in one half and the referee in the other with an arrow
between them.

Inter-file cross-references must also be provided.

.SS DEPENDENCY STRUCTURE
Some elements of the document will be dependent on others.  If the latter
are changed, the former must be recomputed.  A dependency structure similar
to a cross-reference structure is needed to represent this.

.SS DISPLAY AREA STRUCTURE
This is the tree structure of display areas imposed by VTS and ALTO design.

.SS HISTORY STRUCTURE
The history list maintained for undoing changes is a structure that
pretends to have extension in time.  A possible generalization of this is a
context structure.  The usual way to display history structure is to
actually display successive states in either reverse or forward temporal
order.  A useful adjunct might be display of a list of changes of state,
or better, a network revealing the interdependencies of these changes.

.SS STRUCTURER
A program called the "structurer" will enable any machine-readable document
to be parsed into OGDEN form, providing at least the following structures:
fragment, paginated, and outline.  The structurer will be driven by a syntactic
description of the document, taking advantage of the internal consistency
of format of printed and professionally typed material.
.SEC EDITING CONSIDERATIONS
.SS CREATION OF BOXES
A box is an important kind of molecule.
When one is created, its location in galley structure is
told as well as its format, e.g., "indented quotation".  One
way to represent box formats graphically is with a menu of
outlines.  The user can select an outline, position it on the
screen, and fill in its interior with sub-boxes, other molecules, and atoms.

.SS TEXT BOXES
Text boxes are fairly simple, but problems of variable spaced fonts,
a large repertoire of characters, and underlining must be tackled.

.SS MATH BOXES
Non-cartesian two-dimensional formalisms have their own problems and
require special handling.
The input notation could be Algol-like or two-dimensional.  The latter is
harder to implement.  Math boxes frequently occur in text.

.SS GRAPHICS BOXES
Both line drawings and half-tones should be representable with captions.
It is possible that we will allow creation of line drawings in the editor,
but another approach for all graphics is to generate them elsewhere and
merely provide in the editor for their inclusion in a document.

.SS VOICE BOXES
A voice box can be played but not seen.  It often will have a caption.
It should be creatable in the editor.  Audio compaction and speech speedup
are areas we will have to study extensively.

It may be possible to edit speech if phrases are discrete.  Bouncing-ball
visible representations of length, amplitude and stress may be of
assistance in this.

.SS TRANSFER AND EXCHANGE OF BOXES
There are two ways to specify movement of an atom or molecule within
the structure currently displayed (usually a format structure).
One way is NLS-style, where the source is demarked,
the destination is signified, and the command is given.
The other is ATTACH-style, where
the source is "cut" out of the document, the destination is signified,
and the material is "pasted" in at that point.  The main difference is that
while hunting for the destination, the attach method allows the user to
see the cut material (or part of it) on the screen at the location of the
cursor.  The cut-and-paste concept may also be more intuitive.

.SS ROTATION
In later systems, a rotation capability may be available.
If a box is not circular, there is a question of whether rotation causes
the outline to rotate or just the contents.  If the latter, are the
contents clipped?  Should rotation even be allowed?

.SS EXPANSION
Scaling of pictures is an important capability, and may belong in the
editor.  Scaling of text is also useful, but may be considered "font
changing" in a simple system.
.SEC FORMATTING METHODS
.SS RAGGED DISPLAY
The document could be displayed "ragged" during editing.
This is convenient when an 8.5"x11" page can not be displayed with
characters large enough for easy editing.  However, the user should
be able to request a view of fully formatted text and see it
immediately.  There are several methods of handling this.

.SS GALLEY DISPLAY METHOD
In the "galley display method", each
fragment is displayed fully formatted with respect to left and right
margins, but page boundaries are not marked, footnotes and diagrams
are placed near the relevant text, and headings and footings are
incomplete.  Cross-references to pages and similar items are either
estimated or dummied in (e.g., ****).

It should be possible to edit in formatted form.  To minimize
eyestrain, a zooming capability could be provided.

Upon command, any fragment would be paginated, but if an attempt were
made to edit that fragment, it would first revert to galley form.

Justification and hyphenation should be available at the option of
the user.

.SS PAGINATED DISPLAY METHOD
This method requires continuous maintenance of a fully paginated
document during editing.  Any change which affects the length of a page,
the referent of a diagram, a cross-reference target, or the like would
require incremental re-pagination.  This could easily propagate to the
end of the fragment or even to the end of the document.  For short
documents, it would be easy to keep up, but it is not clear whether
that is true for long documents.

.SS MIXED METHODS
It would be possible to defer re-pagination of those pages of the
document which the user is not looking at to make the paginated
display method give better response.  Cross-references would have
to be estimated or dummied in.

Several methods could be provided having different performance
characteristics.  Either the system or the user could choose the one
most appropriate for the particular blend of attributes belonging
to the document at hand.

.SS INCREMENTAL FORMATTING
No matter what display method is employed, incremental formatting
probably will be necessary.  This is simplified by confining the scopes
of modes to local domains such as fragments and groups.  To handle
interdependencies, either state information will have to be kept
for each increment, or dependent values will have to be estimated or
dummied in at times.

.SS AUTOMATIC VS USER-DIRECTED FORMATTING AND PAGINATION
The system should in general do as much work as possible for the
user, but in cases such as pagination there are esthetic judgments
to be made which can not be delegated.  The system can do its
best and let the user intervene to improve its decisions.

.SS CROSS-REFERENCES
Some of the problems of cross-references have been discussed above.
Distinctions must be made about the type of the value of a cross-
reference, e.g., page number, section number, file name.
Targets of cross-references may be specified by pointing or by naming.

.SS INDICES
It is possible to maintain a sorted index continuously, or to maintain its entries
continuously but sort it all at once, or to construct it as a separate
process altogether.  Selection of entries to be indexed and the form
in which they are to appear may be made instance-by-instance by the
user, automatically by the system, or by reponses to automatic prompts.

.SS INSETS
Most insets relate to a piece of text and can appear in galleys.  However,
if an inset would be broken by a page boundary, it might be desirable
to reformat the text that it dents so that it can be moved up or down.

In rare cases, an inset does not relate to specific text, as a picture
centered in the middle of a page of text or a series of pictures in the corner
of each page of a book.  This causes grave problems for the galley display
method, because everything it has decided can be altered drastically during
pagination.

.SS COMPUTED TEXT
Although most text is literal, some is variable, to be computed by the
system instead of entered by the user.  Examples are the date of a letter,
an address that can be computed from a name, and the sum of a column of
figures.

The dependency of computed text on other information should appear
in the structure of the document so that changes to that information
will be reflected in the value of the computed text.  Dependency
structures can accomplish this purpose.

Graphic and voice items can be computed as well; for example, a rectangle
just large enough to outline a segment of text.
.SEC COMMUNICATIONAL INTENTION
.SS INTENTION LANGUAGE
The outline headings of an intentional structure are in a formal
language to make the communicational intention of the material
meaningful to the system.  This is helpful to the user in many ways.

.SS REFERENCE
Intention headings may be used simply as labels.  The user can ask to
view the material so labelled or may specify a cross-reference target
by stating the heading.  These uses of intention headings are trivial,
but disambiguation and spelling correction may gain by the formality
of the intention language.

.SS VERIFICATION
The system ca be asked to verify the soundness of an argument or the
completeness of a explanation by analyzing the statements of
communicational intention.

.SS EXPOSITION
A document can "read itself" to a user by following the train of thought
symbolized by the statements of communicational intention.  This reading
process will be partly interactive, but the system can help the user
by suggesting things to read.  These suggestions can also be influenced
by awareness of the user's knowledge as recorded in the user model.
After the user has read something, the system can update the user
model based on the formal statements of communicational intention.

.SS COMPOSITION
It is feasible to provide automatic composition of letters and of first
draft reports.  The user could say "write a letter to Joe Doe about
the new spocket technology", and the system would select material
guided by its intention to explain spocket technology and by knowledge of
previous correspondence with Joe Doe.  Automatic abstracting might also
be facilitated by intentional structure.
.SEC IMPLEMENTATIONS
.SS EXPERIMENTAL SYSTEMS
Experimental systems will be tried on a handful of users to
minimize widespread distress.  Most experiments will be made
first in OGDEN and only after some success will they be repeated
in less flexible small-machine implementations.

.SS PRODUCTION SYSTEMS
A simple production system should be brought up as soon as
possible.  It should evolve in parallel with the experimental
systems, but should lag it enough so that transient perturbations
are dampened.  Even "production" systems should be regarded as
essentially experimental and subject to the axe.

.SS MAXC/VTS
The primary experimental vehicle will be a system running on MAXC
through the MCA to the VTS.  This system will be for one user at a
time to try out new ideas and reject bad ones before they are
implemented at lower levels.  The programming language will be LISPX.

Once a primary system gains acceptance in single-user use, it will
be programmed for small machines.

.SS NOVA/VTS
One possible small machine configuration consists of several NOVAs
hooked to the the Video Terminal System.  Possible programming
languages are MPL (when it works), LISPX (if it works), and BCPL
(if we can work it).

.SS ALTO
Another small machine configuration consists of several ALTOs
operating mostly independently with central connections to
shared facilities such as microfiche libraries and XGPs.
Possible programming languages are LISPX, SMALLTALK, MPL, and BCPL.

.SS MODULARITY AND DISTRIBUTED SYSTEM ORGANIZATION
It is possible for one machine to be performing many functions
for one user (usual ALTO mode) or to be performing one function
for several users (e.g., a VTS NOVA).  Modules should be
programmed so that they can be used in either way.  That is,
several functional modules may be loaded into one machine and
told to service one user, or one functional module may be
loaded and told to service many users.

One way to distribute processing is to consider each module to be a
responsible party.  When it is assigned a task, it is expected
to complete the task even if its normal procedure does not work.
If it assigns subtasks to other modules, it should verify that
they are completed correctly and on time (as far as it is possible
to tell).  When they are not, they should be re-assigned to other
modules, such as old versions of programs and modules resident
in other machines.  When all else fails, an explanation should be
reported to the module that assigned the task.  Trouble reports
should be filed in a central facility if possible.

Inter-module protocols should be simple, but not so barren as to
stifle redundancy checking and verification.

For many purposes, the user may be thought of as a module.  Thus,
posting boards can list needs to be satisfied by any module
willing including the user.  However, carrying this notion too far
may produce an uncomfortable mode of interaction for the user.
.SEC MEASUREMENT AND EVALUATION
.SS LEVELS OF REJECTION
Most ideas can be rejected as soon as they are conceived.
Most of the ideas that are actually pondered can be rejected before
they are spoken.  Most of the ideas that are discussed can be
rejected before they are programmed.  Many of the ideas that are
programmed will be dumped or drastically revised before completion.
Many of the ideas that are actually programmed will be rejected
by the programmer or colleagues during initial testing.

The surviving ideas will be tried on a few potential users among
the people working at PARC.  We will avoid pulling the rug out
from under our secretaries very often.

.SS PERFORMANCE AND UTILIZATION MONITORING
We should include performance and utilization monitoring in our
programs both to locate opportunities for improved performance
and to discover the frequency of use and success of various
features.

.SS USER ACCEPTANCE MEASURES
Ways of obtaining and recording subjective evaluations from users
should be developed.

.SS COMPARISON OF ALTERNATIVE SYSTEMS
It will not always be clear that one system is entirely superior to
another.  Some features may be better in one and some in the other.
A particularly bad feature can drag down others that would be
acceptable were that one improved.  Thus, measures should include
several variables and their interactions should be noted.
.STANDARD BACK